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C. S. Draper Laboratory 
Cambridge, Massachusetts 

LUMINARY Memo #162 

To: Distribution 

From; D. Eyles 

Date: 20 July 1970 

Subject: A New Landing Analog Displays Routine 

This memo describes a new Landing Analog Displays (LAD) routine now 
running and essentially complete in revision 31 of off-line program ZERLINA. 

A copy of PCR 1058 for its incorporation in LUMINARY is attached. 

This version aims at reducing computational errors to zero. By com- 
putational errors I exclude Servicer's state vector errors, including only 
those errors due to imperfect extrapolation of Servicer data. Specifically, 
these weaknesses of the incumbent LAD had to be cured: (1) a periodic "lurch" 
in the altitude-rate displayed on the tape meter, caused by a time-inconsistency 
in the LAD-Servicer interface, (2) excessive granularity of the DSKY display — 
in R1 of noun 60 during P66 — of forward velocity, and (3) inaccuracy of the 
cross-pointer displays. 

These problems were attacked (1) by insuring time-consistency of the 
LAD inputs from Servicer, (2) by adding a PIPA bias correction term to the 
velocity computation which is the starting point of the LAD calculations, (3) by 
a more adroit choice of scaling, and (4) by the use of double -precision arith- 
metic at strategic points, partially compensated for, in terms of execution 
time, by simplifications elsewhere. Also, care was taken to avoid the 
possibility of cumulative errors, the bane of an open loop driven incrementally. 

Tests show that the design objective — in a word, accuracy — is achieved. 
Bob Covelli, who wrote an edit for the purpose, observed computational errors 
in the old version of up to 6 bits. (One bit is worth . 5571 f/s. ) This error is 
reduced to at most one bit. More important, in the neighborhood of zero 
velocity the maximum error is less than a bit, because velocity is rounded to 
the nearest bit before being displayed. This means that when forward or 
lateral velocity exceeds about . 3 f/s, either way, the cross -pointers can be 
relied upon to show it as non-zero. Thus in switching into P66 Auto from 
attitude-hold with the spacecraft erect and the cross-pointers at zero no 
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perceptible attitude transient will occur. In the old version velocity sometimes 
has to be more than 1. 2 f/s for the cross-pointer to move away from the zero 
mark. The accuracy of the altitude-rate display is also improved, and the 
annoying "lurch” eliminated. 

This new LAD routine saves about 90 words of fixed memory. Its 
erasable storage requirements are down to 32 cells from 40 cells. In execu- 
tion time the new version takes about 1. 5 ms. more than the old version every 
1/4 second, plus 5 ms. more every 2 seconds, a dutycycle increase of about 
. 85%. 

The major changes involved are next described. Note that items C - E 
are positive improvements not directly inspired by the shortcomings of the old 
version. 

A. The addition of a PIPA bias correction term to the velocity vector 
computation was thought worthwhile. The PIPA compensation scaling allows 
for a bias of up to 12.5 cm/s over 2 seconds, and a bias of this size would 
affect the accuracy of the LAD displays significantly. The velocity computation 
becomes: 

VVECT = V - VSURFACE -f (PIPA - PIPAOLD) + (G-VBIAS) DT, 

V is the velocity vector for PIPTIME, VSURFACE is the lunar surface 
velocity, both from Servicer. PIPAOLD contains the contents of the PIPAs 
at PIPTIME; it also comes from Servicer, as described in Luminary Memo 
#152 about the Cyclical PIPA Reader. G-VBIAS (only one mnemonic) is 
computed by Servicer every pass as the acceleration due to gravity minus the 
pseudo-acceleration due to PIPA bias. The computation of VBIAS (needed 
by P66ROD) formerly done at the start of P66 was moved to NORMLIZE (the 
Servicer job lead-in) and VBIAS in turn is used every pass in the computation 
of G-VBIAS. DT is simply time since PIPTIME. All the vectors are in 
stable-member coordinates. 

B. In addition, a simpler altitude extrapolation is used than before, 
one analogous to the position computation in average-G where the average 
of velocities at either end of an interval is used to extrapolate position. 


ALTITUDE = HCALCLAD + 


ALTRATE + HDOTLAD 


DT 
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where HCALCLAD and HDOTLAD are altitude and altitude-rate at PIPTIME 

provided by Servicer. ALTRATE is the current altitude-rate calculated just 
before in the LAD routine. 

C. An additional advantage of the new LAD is that it starts displaying 
when average-G is turned on at TIG -30 seconds instead of waiting for 
ignition. LAD never had to wait for ignition and by enabling itself earlier 
provides an additional confirmation that Servicer is working properly before 
the engine is lit. The flag SWANDISP which enables the displays is set by 
Servicer whenever it provides the interface variables; this first occurs soon 
after TIG - 30 seconds. Formerly SWANDISP was set at TIG by descent and 
ascent programs. 

D. The new LAD effectively issues tape meter updates with twice the 
frequency of the old routine, every 1/4 second instead of every 1/2 second. 

This is because the old routine issues altitude and altitude-rate alternately, 
each every 1/2 seconds. But since it is the channel bits which are set following 
the altitude output that actually cause the meters to move, altitude-rate has to 
wait 1/4 second before being seen. This is objectionable, since in computing 
altitude-rate we take such pains to be up-to-date. In the new version altitude- 
rate is output before a 3 centisecond break (necessary anyway to fragment 

this long interrupt) and altitude afterwards. Without a break this would be 
impossible as time must be allowed for altitude-rate to be read out of the 
ALTM register (ECADR 60) before altitude is put in. Since the altitude 
computation is a quick one, and altitude cannot be computed without first 
getting altitude -rate, very little computation time would be saved by forcing 
the new LAD to emit these displays with the old frequency. And it would 
cost words. 

E. Finally, the RIOFLAG, which used to prevent the computation and 
display on the cross-pointers of forward and lateral velocity during ascent 
and aborts, is eliminated. Lateral velocity, in particular, may be useful in 
telling whether an ascent burn has an out-of-plane component. Involved in the 
cross-pointer calculations is the assumption that the stable-member y-axis 

is approximately normal to the LM (and CSM) orbital plane. This is the normal 
alignment for ascent, but since the assumption is not made anywhere else in 
the ascent coding, it should be explicitly recognized that the accuracy of the 



cross-pointer displays during ascent depends on its validity. 

Now a word on computational simplifications. 

The Landing Analog Displays begin by computing a velocity vector, 
relative to the surface. This vector is projected along (dotted with) unit 
vectors RUNIT, UHYP and UHZP to get altitude -rate, VHY and VHZ, and 
finally VHY and VHZ are resolved into forward and lateral velocity according 
to the outer gimbal angle. Great simplifications are possible in the area of 
the dot products, saving execution time (expended elsewhere) and making 
possible the elimination of the erasables UHYP and UHZP, for a total of 12 
cells in ebank ?„ four of which are expended. 

The key assumption is the identity of UHYP and the stable-member y- 
axis. This assumption is easily made — at least for descent — since they are 
defined the same way, as the northward or right-hand normal to the LM (and 
CSM) orbital plane. That the two are equivalent is assumed already in the 
final stage of the cross-pointer computations, where the sine and cosine of 
the outer gimbal angle are used to resolve VHY and VHZ into forward and 
lateral velocity, so the two might as well be identified, and the vector UHYP 
eliminated entirely. VVECTY becomes VHY. Furthermore, since UHZP = 
UNIT(R) - UHYP, the y-component of UHZP disappears, and with it the middle 
term of the VHZ dot product. Finally, note from this drawing 
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in which the stable -member y-axis extends out of the page toward you, that 
UHZPX = - RUNITZ 
UHZPZ = RUNITX. 

This permits the elimination of UHZP. 

It has been suggested that the y-component of the altitude-rate dot 
product can also be eliminated. This is true for the so-called landing align- 
ment but not necessarily true for ascent. Although the assumption of this 
alignment is made for the cross-pointer computations (as noted above in E) 
it was not thought best to make it for the more essential computation of 
altitude -rate. 

Next come descriptions of LAD inputs and outputs, a flowchart, and 
a copy of PCR 1058. 
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INPUTS 


Besides the 
by Servicer 

V 

VSURFACE 

G-VBIASX, 

RUNITX, Y, 

PIPAOLD 

PIPTIME 

HCALCLAD 

HDOTLAD 

DALTRATE 

M22 


current contents of the PIPAs LAD's inputs are these, provided 
unless otherwise noted: 

Velocity at PIPTIME, SM coordinates, scaled in units 
of 2 m/cs. Three DP components 

Lunar surface velocity, SM coordinates, scaled in units of 

5 

2 m/cs. Three DP components. This replaces DELVS 
but has the opposite sign. 

I ^ Z Acceleration due to gravity minus pseudo-acceleration 

due to PIPA bias, SM coordinates, in units of 2 m/cs/cs. 
Three SP components. 

Z Unit position vector, SM coordinates, scaled full-size. 

Three SP components. 

(Actual mnemonics PIPAXOLD, PIPAYOLD, and PIPAZOLD) 
The contents of the PIPAs as of PIPTIME (see Lum. Memo 
#152). Three SP components. 

Time at which all these numbers are valid, TIME2 units. 

DP scalar. (Actually, only the low-order part is used. ) 

Altitude at PIPTIME, in units of 2^^ meters, a DP scalar. 

Altitude-rate at PIPTIME, in units of 2^ m/cs, a DP 
scalar. 

Rate-of-change of altitude-rate due to change in the direction 
of RUNIT, scaled in units of 2 ^ m/cs/cs, a SP scalar. 

Sine of the outer-gimbal angle, full- size, kept up to date 
by the DAP, a SP scalar. 

Cosine of the outer-gimbal angle, full-size, kept up to 
date by the DAP, a SP scalar. 
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OUTPUTS 


Besides its outputs to the cross-pointers and tape meters, LAD maintains 

the following variables, never more than 1/4 second old while LAD is running: 

VVECTX, Y, Z Velocity relative to the lunar surface in SM coordinates, 

in units of 2 m/cs. Three DP components. 

ALTITUDE Altitude in units of 2^^ meters. 

ALTRATE Altitude-rate in units of 2 m/cs. (This could be used 

for R2 of nouns 60, 63, 64, and 92 for the DSKY 
altitude-rate display to be more up-to-date when it 
appears. ) 

FORVMETR Forward velocity in meter units, . 5571 f/ s/bit, a 

SP scalar. 

LATVMETR Lateral velocity in meter units, . 5571 f/s/bit, a 

SP scalar. 

5 ' 

FORVEL Forward velocity for DSKY display, units of 2 m/cs, 

a DP scalar. 


7 



enter every 1/4 second 



end 
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1.3 EAFECTIVITY 

LUMINARY IE (Apollo 15) 
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New Landing Analog Displays (RIO) 
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See attached sheet. 
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PROGRAM CHANGE 

PREPARED BY: _ 

EYLES 

ORGANIZATION: 

REQUEST NO. lOS’-ft 

DATE: _ 

July 6, 1970 

MIT 


CONTINUATION SECTION (REFER TO BLOCK NUMBER AND TITLE 

ON PROGRAM CHANGE REQUEST FORM) 

1.5 Reasons for Change: 

(1) Eliminate errors in forward and lateral velocity displayed on the 
cross-pointers. 

(2) Eliminate the periodic "lurch” in the altitude-rate displayed on 
the tape meter. 

(3) Correct error and excessive granularity of the forward velocity 
displayed in R1 of noun 60 (during P66). 

(4) Speed up display of altitude and altitude- rate (display each every 
1/4 second instead of every 1/2 second as at present). 

(5) Begin displaying analog data at TIG - 30 seconds when average -G 
is turned on instead of waiting for ignition. 

(6) Eliminate the RIOFLAG so that cross-pointer displays be available 
during ascent and aborts as well as descent. 


1.6 Description of Change: 

Incorporate in LUMINARY the LAD routine now running in off-line program 
ZERLINA. GSOP impact aspects of this change are (1) the addition of a PIPA bias 
correction term to the velocity computation which is the starting point of the LAD 
computations, and (2) a simpler altitude extrapolation: 


ALTITUDE 


IIDOTLAD + ALTRATE 
2 


DT + HCALCLAD 


where HDOTLAD and HCALCLAD are altitude-rate and altitude at PIPTIME, DT is 
time since PIPTIME, and ALTRATE is the current altitude-rate computed by LAD. 
Items 4-6 under "Reasons for Change" may require minor GSOP modifications, too. 


REMARKS 

This change is not dependent on approval of the Variable Guidance Period 
Servicer (PCR 1024) but could most conveniently be put into LUMINARY at the 
same time as that larger change. 



